Skip to content

SREP-413: Prevent false UpgradeConfigValidationFailedSRE alert after …#573

Open
Alcamech wants to merge 1 commit intoopenshift:masterfrom
Alcamech:SREP-413
Open

SREP-413: Prevent false UpgradeConfigValidationFailedSRE alert after …#573
Alcamech wants to merge 1 commit intoopenshift:masterfrom
Alcamech:SREP-413

Conversation

@Alcamech
Copy link

@Alcamech Alcamech commented Feb 6, 2026

SREP-413: Prevent false UpgradeConfigValidationFailedSRE alert after upgrade completes

What type of PR is this?

Bug

What this PR does / why we need it?

When an UpgradeConfig is recreated by the UpgradeConfigManager (due to spec changes from OCM after an upgrade completes), the status/history is lost. The controller would then create a new history entry with Phase: New, run validation, and fail because the desired version matches the current version - triggering a false UpgradeConfigValidationFailedSRE alert.

This PR adds a check for HasUpgradeCompleted() before defaulting to Phase: New. If CVO confirms the upgrade already completed, we create the history entry with Phase: Upgraded, bypassing validation entirely and preventing the false alert.

Which Jira/Github issue(s) this PR fixes?

SREP-413

Special notes for your reviewer:

If StartTime or CompleteTime cannot be extracted from CVO history (e.g., CVO's CompletionTime is nil), the synthetic history entry may have nil timestamps. This could cause a panic in reportUpgradeMetrics() at line 310. Should we add nil checks or default to time.Now() as a fallback ?

A/B Testing Results

Without the fix in place on a fresh CR containing the same version with no .status section I get the following logs

ts=2026-02-26T20:36:51.487379598Z level=info logger=controller_upgradeconfig msg="Reconciling UpgradeConfig" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:36:52.469257152Z level=info logger=controller_upgradeconfig msg="Current cluster status" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config status=Pending
ts=2026-02-26T20:36:52.469290363Z level=info logger=controller_upgradeconfig msg="Validating UpgradeConfig" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:36:52.519272745Z level=info logger=controller_upgradeconfig msg="4.17.1 is equal to 4.17.1" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:36:52.51928334Z level=info logger=controller_upgradeconfig msg="An error occurred while validating UpgradeConfig: desired version 4.17.1 matches the current version 4.17.1" 

With the fix in place I get the following logs instead

2026-02-26T20:43:20.841943538Z level=info logger=controller_upgradeconfig msg="Reconciling UpgradeConfig" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:43:21.545947059Z level=info logger=controller_upgradeconfig msg="Upgrade already completed for this version, setting phase to Upgraded" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:43:21.864495561Z level=info logger=controller_upgradeconfig msg="Current cluster status" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config status=Upgraded
ts=2026-02-26T20:43:21.864511521Z level=info logger=controller_upgradeconfig msg="Cluster is already upgraded" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config

Without fix With fix
Phase Pending (stuck in loop) Upgraded (immediate)
Validation Runs, fails: "4.17.1 matches 4.17.1" Skipped entirely
Alert UpdateMetricValidationFailed fires No alert
Behavior Endless reconcile loop paging SREs Single reconcile, done

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Feb 6, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Feb 6, 2026

@Alcamech: This pull request references SREP-413 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

SREP-413: Prevent false UpgradeConfigValidationFailedSRE alert after upgrade completes

What type of PR is this?

Bug

What this PR does / why we need it?

When an UpgradeConfig is recreated by the UpgradeConfigManager (due to spec changes from OCM after an upgrade completes), the status/history is lost. The controller would then create a new history entry with Phase: New, run validation, and fail because the desired version matches the current version - triggering a false UpgradeConfigValidationFailedSRE alert.

This PR adds a check for HasUpgradeCompleted() before defaulting to Phase: New. If CVO confirms the upgrade already completed, we create the history entry with Phase: Upgraded, bypassing validation entirely and preventing the false alert.

Which Jira/Github issue(s) this PR fixes?

SREP-413

Special notes for your reviewer:

If StartTime or CompleteTime cannot be extracted from CVO history (e.g., CVO's CompletionTime is nil), the synthetic history entry may have nil timestamps. This could cause a panic in reportUpgradeMetrics() at line 310. Should we add nil checks or default to time.Now() as a fallback ?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

1 similar comment
@openshift-ci-robot
Copy link

openshift-ci-robot commented Feb 6, 2026

@Alcamech: This pull request references SREP-413 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

SREP-413: Prevent false UpgradeConfigValidationFailedSRE alert after upgrade completes

What type of PR is this?

Bug

What this PR does / why we need it?

When an UpgradeConfig is recreated by the UpgradeConfigManager (due to spec changes from OCM after an upgrade completes), the status/history is lost. The controller would then create a new history entry with Phase: New, run validation, and fail because the desired version matches the current version - triggering a false UpgradeConfigValidationFailedSRE alert.

This PR adds a check for HasUpgradeCompleted() before defaulting to Phase: New. If CVO confirms the upgrade already completed, we create the history entry with Phase: Upgraded, bypassing validation entirely and preventing the false alert.

Which Jira/Github issue(s) this PR fixes?

SREP-413

Special notes for your reviewer:

If StartTime or CompleteTime cannot be extracted from CVO history (e.g., CVO's CompletionTime is nil), the synthetic history entry may have nil timestamps. This could cause a panic in reportUpgradeMetrics() at line 310. Should we add nil checks or default to time.Now() as a fallback ?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 6, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Alcamech
Once this PR has been reviewed and has the lgtm label, please assign tkong-redhat for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@codecov-commenter
Copy link

Codecov Report

❌ Patch coverage is 92.30769% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.47%. Comparing base (b43d6ec) to head (13b927d).
⚠️ Report is 2 commits behind head on master.

Files with missing lines Patch % Lines
...trollers/upgradeconfig/upgradeconfig_controller.go 92.30% 1 Missing and 1 partial ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #573      +/-   ##
==========================================
+ Coverage   54.35%   54.47%   +0.11%     
==========================================
  Files         123      123              
  Lines        6123     6139      +16     
==========================================
+ Hits         3328     3344      +16     
  Misses       2592     2592              
  Partials      203      203              
Files with missing lines Coverage Δ
...trollers/upgradeconfig/upgradeconfig_controller.go 81.60% <92.30%> (+1.50%) ⬆️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 6, 2026

@Alcamech: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/validate 13b927d link true /test validate

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Feb 26, 2026

@Alcamech: This pull request references SREP-413 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

SREP-413: Prevent false UpgradeConfigValidationFailedSRE alert after upgrade completes

What type of PR is this?

Bug

What this PR does / why we need it?

When an UpgradeConfig is recreated by the UpgradeConfigManager (due to spec changes from OCM after an upgrade completes), the status/history is lost. The controller would then create a new history entry with Phase: New, run validation, and fail because the desired version matches the current version - triggering a false UpgradeConfigValidationFailedSRE alert.

This PR adds a check for HasUpgradeCompleted() before defaulting to Phase: New. If CVO confirms the upgrade already completed, we create the history entry with Phase: Upgraded, bypassing validation entirely and preventing the false alert.

Which Jira/Github issue(s) this PR fixes?

SREP-413

Special notes for your reviewer:

If StartTime or CompleteTime cannot be extracted from CVO history (e.g., CVO's CompletionTime is nil), the synthetic history entry may have nil timestamps. This could cause a panic in reportUpgradeMetrics() at line 310. Should we add nil checks or default to time.Now() as a fallback ?

A/B Testing Results

Without the fix in place on a fresh CR containing the same version with no .status section I get the following logs

ts=2026-02-26T20:36:51.487379598Z level=info logger=controller_upgradeconfig msg="Reconciling UpgradeConfig" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:36:52.469257152Z level=info logger=controller_upgradeconfig msg="Current cluster status" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config status=Pending
ts=2026-02-26T20:36:52.469290363Z level=info logger=controller_upgradeconfig msg="Validating UpgradeConfig" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:36:52.519272745Z level=info logger=controller_upgradeconfig msg="4.17.1 is equal to 4.17.1" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:36:52.51928334Z level=info logger=controller_upgradeconfig msg="An error occurred while validating UpgradeConfig: desired version 4.17.1 matches the current version 4.17.1" 

With the fix in place I get the following logs instead

2026-02-26T20:43:20.841943538Z level=info logger=controller_upgradeconfig msg="Reconciling UpgradeConfig" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:43:21.545947059Z level=info logger=controller_upgradeconfig msg="Upgrade already completed for this version, setting phase to Upgraded" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config
ts=2026-02-26T20:43:21.864495561Z level=info logger=controller_upgradeconfig msg="Current cluster status" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config status=Upgraded
ts=2026-02-26T20:43:21.864511521Z level=info logger=controller_upgradeconfig msg="Cluster is already upgraded" Request.Namespace=openshift-managed-upgrade-operator Request.Name=managed-upgrade-config

Without fix With fix
Phase Pending (stuck in loop) Upgraded (immediate)
Validation Runs, fails: "4.17.1 matches 4.17.1" Skipped entirely
Alert UpdateMetricValidationFailed fires No alert
Behavior Endless reconcile loop paging SREs Single reconcile, done

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@ravitri
Copy link
Member

ravitri commented Mar 4, 2026

/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 4, 2026
// the UpgradeConfig was recreated (e.g., by UpgradeConfigManager due to spec changes)
// after an upgrade finished, causing the status/history to be lost.
if cvClient.HasUpgradeCompleted(clusterVersion, instance) {
reqLogger.Info("Upgrade already completed for this version, setting phase to Upgraded")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With reference to https://github.com/openshift/managed-upgrade-operator/blob/master/pkg/upgraders/controlplanestep.go#L53-L64, CVO marking Upgrade completed was Control plane upgrade only but not worker plane upgrade. Thus that's being tracked separately. If indeed this has changed on CVO side as well then we would need to align the upgrade steps too which is a separate prerequisite change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants